<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"></meta>
    <title>readme</title>
  </head>
  <body>
     <h1>Google Search Appliance (GSA) Valve Security Framework</h1>
     <p>
      <font size="5">
       Readme</font><br>
    </p>
     <p>
      Strategic and secure information sources are naturally becoming key repositories that customers want to make searchable. Since search is a platform and not just an application commodity, it is a pre-requisite to cope with heterogeneous security systems in order to seamlessly roll-out an Enterprise-wide secure search capability. 
    </p><p>
      The search appliance can nicely integrate with popular single sign-on (SSO) systems, forms-based authentication systems and negotiate HTTP Basic and NTLM authentications/authorizations. However, it can&rsquo;t substitute the need for a unified authentication process across all secure sources. Heterogeneous sources may require different sets of credentials which make the search experience painful for the end-user, having to authenticate multiple times when querying. Additionally, the appliance may not be able in certain cases to cope with
      complex and non-standard authentication and/or authorization processes
      which may put at risk the deployment of search technology. 
    </p>
    <p>
      The GSA Valve Security Framework was designed to answer both of these issues. It exposes a global authentication capability to the search user and then loads transparently the sets of credentials that are relevant to each indexed sources. It is a framework that can easily be extended to support the specifics of new repositories in terms of authentication and authorization processes. You can easily extend it creating new authentication and authorization modules that offer new capabilities making the Security Framework fully working with your custom content repositories.



    </p><p>
      This authentication and authorization framework acts as a content proxy
      and can be considered as a quick, simple and low-cost alternative to a
      single sign-on (SSO) system. It can be integrated as well with third-party
      SSO solutions in those situations where the corporate SSO doesn&rsquo;t
      secure all the searchable applications. 
    </p><p>
      This framework supports two different interfaces for serving content in
      the search appliance:
      <ul> 
      <li>
      <b>Forms Based Authentication (Web Single
      Sign-On)</b>: the primary frontend that was supported from the beginning was
      Forms Based Authentication as it&rsquo;s known in the GSA terminology. It
      really acts as a Single Sign-On, as the user has this experience and all
      the request are treated by this frontend. 
      </li>
      <li>
      <b>SAML (Security Assertion
      Markup Language)</b>: this is a security standard supported by the GSA. Since
      GSA Security Framework version 2, it&rsquo;s offered a SAML-enabled
      frontend.
      </li>
      </ul>
    </p><br>
    <h3>
      Latest Changes
    </h3><p>
      <strong>Release 2.0 - June 18 2008</strong>
    </p><ul>
      <li>
         SAML frontend that can be used as an alternative mechanism&nbsp;to&nbsp;the&nbsp;Forms&nbsp;Based&nbsp;one to be integrated with the Google Search Appliance (GSA). It supports exactly the same scenarios as the Forms Based one does. 
      </li>
      <li>
        The root Authentication and Authorization processes have been redisigned to be more scalable.
      </li>
      <li>
        A new attribute at the repository level, checkAuthN, permits not to process any authentication classes. This is useful when the authentication module created for integrating a repository, is not necessary to be processed due to whatever reason (it was already processed by another module, only authZ oriented, ...)
      </li>
      <li>
        The referer cookie can be now set&nbsp;up in the config file.
      </li>
      <li>
        Authentication cookie&nbsp;content&nbsp;is&nbsp;now&nbsp;URL encoded.
      </li>
      <li>
        Code documentation
      </li>
      <li>
        Session implementation has been improved to solve some issues.
      </li>
      <li>
        Some other minor issues&nbsp;found&nbsp;in&nbsp;projects have been solved.
      </li>
    </ul><p>
      <strong>Release 1.4.1 - March 19 2008</strong>
    </p><ul>
      <li>
        Error management feature added. It shows customized errors messages
      </li>
      <li>
        Max age is now implemented in all the authentication cookies
      </li>
      <li>
        Basic AuthN/AuthZ: new cookie information avoiding the use of &quot;Basic &quot;&nbsp;
      </li>
      <li>
        Sessions are now synchronized
      </li>
      <li>
        setIsNegotiate method has been deleted from the authentication process classes
      </li>
    </ul>
    <p>
      <strong>Release 1.4 - Jan 07 2008</strong> </p>
    <ul>
      <li>Added support to Kerberos authentication </li>
      <li> Added support for managing
      Sessions in the Valve. It's also able to store cookies in the session </li>
      <li> New deployment scenarios implemented in the Valve, including the
      possibility to mix both Kerberos and non Kerberos authentication </li>
      <li> New
      Kerberos servlet that suports Kerberos native authentication </li>
      <li>      Authenticate servlet supports now multiple credentials both for Kerberos
      and Username/Password </li>
      <li> The Valve configuration file has been extended to
      support both Kerberos and Sessions </li>
      <li> New package architecture that
      organizes the authentication and authorization modules </li>
      <li> LDAP
      configuration have been moved to the configuration file. The same for
      LDAPSSO.</li>
      <li> New URL encoding processing compatible with Windows sources </li>
      <li> Authentication Cookies obtained from the sources can be sent back to the
      browser and/or stored in the session for further
      authentication/authorization </li>
      <li> New Credentials implementation managed
      through a Vector </li>
      <li> Root authentication is now independent from the
      credentials, that have to be sent by a Credentials object </li>
      <li> HTTPBasic and
      Kerberos authorization now efficiently treats HEAD requests coming from
      the GSAs </li>
      <li> New utilities have been created to process files when
      authorizing. These classes can be used by all the AuthN/AuthZ modules </li>
      <li> More efficient non HTML file authorization processing. The processing is
      made in memory by document blocks, instead opening the whole document </li>
      <li> HTTPVisitor class now supports more processing cases </li>
      <li> Multiple HTTP
      connections support. The number of connections are now configurable in the
      config file </li>
    </ul>
    <p><strong>Release 1.3.1 - Nov 22 2007 </strong></p>
    <ul>
      <li>Fixed problem of returning back to search
        page after inital login at start of authN process. The valve first looks
        for a referer header and if it exists and is a valid GGSA host it will
        create a cookie At the point where the valve redirects back to the search
      page it will do one of the following (in order)
        <ul>
          <li> Use the valve set in the
            gsaRequestHost cookie if it exists </li>
          <li> Look for a gsaHost parameter in the
              search query sting </li>
          <li> Use the first GSA host defined in the searchHosts
                array in the valve configuration file</li>
        </ul>
      </li>
      <li>Version number of the build now
      including in the name of the valve.jar (valve_${version}.jar) </li>
    </ul>
    <p><strong>Release 1.3 - Oct 28
        2007 </strong></p>
    <ul>
      <li>Added support to configure the valves authN and authZ classes via an
            xml configuration file. </li>
      <li>Added support for multiple GSAs using the same
            Valve Security Framework&nbsp; <br>
    </li>
    </ul>
    <br>
	<h3>More&nbsp;Information </h3>
    <p>
      Check the latest documentation available at &lt;<a href="http://code.google.com/p/gsa-valve-security-framework/"> http://code.google.com/p/gsa-valve-security-framework/</a>&gt; in order to know how the application can be deployed and get more information.
    </p>
    <p>
      &nbsp;
    </p>
</body>
</html>
